D-Bus patching session opened

Bluez-devel Marcel Holtmann 2 participants 3 messages Sep 22, 2005 Bluetooth drivers

Share & tools

Marcel Holtmann

author maintainer

2005-09-22 14:28 UTC #0 lore raw

Hi,

after I dropped the D-Bus 0.23 API support it is now time to really play with the integration of D-Bus support into hcid and other daemons. This is the first step into creating a full D-Bus aware bluetoothd in the future.

I like to see some more D-Bus enhancements now and Claudio already started and he's working hard in explaining his work and making me happy. So please help him and review his code and send small patches to make the D-Bus experience better. I think about making the D-Bus a core dependency of bluez-utils. Does anybody have any arguments against it?

Next thing that I like to see are some Python applications that are using GTK+ and D-Bus for a graphical interface to BlueZ. For that I think about creating a bluez-python package. Therefor we need people who are writing the code and other people who are creating some nice fancy icons and graphics for it. First thing should be a D-Bus aware PIN helper written completely in Python.

There exists a job/task for everyone :)

Regards

Marcel

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Claudio Takahasi

2005-09-22 19:13 UTC #1 lore raw

Hi Marcel,

I have some comments and questions:

1. Multiple bluetooth adapters
This is an old discussion but we didn't written it in a stone. Do you plan support address multiple local adapter or not? If yes, we have to plan how define the object path. My suggestion is insert the device id in the path(org/bluez/dev_id/hci, org/bluez/dev_id/pan, ...).

2. Non D-Bus systems
You wrote in an old email: "bluetoothd should combine hcid and sdpd". I didn't understand the scope of this assertion. IMHO in the future for D-Bus enable systems bluetoothd should provide hcid, sdpd and profiles services(D-Bus).
hcid features include control initialize/register) adapters and provide D-Bus services for get adapter infos and basic task like inquiry, scan, remote name, ..
sdpd services include register/unregister local services, control incomming connections and D-Bus services for search services. Regarding sdp services, is it necessary provide a D-Bus service for register/unregister services or we have to use sdp_connect + sdp_device_record_register?

As long as I could understand, bluetoothd will not be only a D-Bus service provider, but it must support NON D-Bus clients too. Is that correct?

3. API version
We have to think how keep the backward compatibility among the future BlueZ D-Bus services versions. I my opinion we have three options:
- create a initialization service for bluetoothd where we can check the version.
- insert an extra arguments in each method call(request)
- define different interface name based on the API version

4. Introspect
It's becomming common implement a Introspectable interface that make possible get a xml string describing the provided services. It can be a good feature support it.

Regards,
Claudio

Quoted 40 lines · Marcel Holtmann

Hi,
after I dropped the D-Bus 0.23 API support it is now time to really play with the integration of D-Bus support into hcid and other daemons. This is the first step into creating a full D-Bus aware bluetoothd in the future.
I like to see some more D-Bus enhancements now and Claudio already started and he's working hard in explaining his work and making me happy. So please help him and review his code and send small patches to make the D-Bus experience better. I think about making the D-Bus a core dependency of bluez-utils. Does anybody have any arguments against it?
Next thing that I like to see are some Python applications that are using GTK+ and D-Bus for a graphical interface to BlueZ. For that I think about creating a bluez-python package. Therefor we need people who are writing the code and other people who are creating some nice fancy icons and graphics for it. First thing should be a D-Bus aware PIN helper written completely in Python.
There exists a job/task for everyone :)
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

author maintainer

2005-09-22 19:55 UTC #2 lore raw

Hi Claudio,

Quoted 8 lines

I have some comments and questions:
1. Multiple bluetooth adapters
This is an old discussion but we didn't written it in a stone. Do you plan support address multiple local adapter or not? If yes, we have to plan how define the object path. My suggestion is insert the device id in the path(org/bluez/dev_id/hci, org/bluez/dev_id/pan, ...).

my idea is that dev_id is only used inside the kernel and by bluetoothd and that the D-Bus interface never exposes it. We should use device names like "hci0" etc. or the device address. In generell the address in unique and we should use it wherever possible, but with some tricks you can have the same address attached to the same machine. However this case is really not normal.

So I think we will use paths like org/bluez/hci0/ or with an address like org/bluez/00:11:22:33:44:55/. For the default adapter we can use the path org/bluez/default/.

Quoted 14 lines

2. Non D-Bus systems
You wrote in an old email: "bluetoothd should combine hcid and sdpd". I didn't understand the scope of this assertion. IMHO in the future for D-Bus enable systems bluetoothd should provide hcid, sdpd and profiles services(D-Bus).
hcid features include control initialize/register) adapters and provide D-Bus services for get adapter infos and basic task like inquiry, scan, remote name, ..
sdpd services include register/unregister local services, control incomming connections and D-Bus services for search services. Regarding sdp services, is it necessary provide a D-Bus service for register/unregister services or we have to use sdp_connect + sdp_device_record_register?

Quoted 3 lines

As long as I could understand, bluetoothd will not be only a D-Bus service provider, but it must support NON D-Bus clients too. Is that correct?

I thought that it would be a good idea to have an additional interface, but I am not sure if that makes sense. Everything is going to use D-Bus and so bluetoothd might only expose its interface over D-Bus. This will make the development a lot easier.

Quoted 8 lines

3. API version
We have to think how keep the backward compatibility among the future BlueZ D-Bus services versions. I my opinion we have three options:
- create a initialization service for bluetoothd where we can check the version.
- insert an extra arguments in each method call(request)
- define different interface name based on the API version

We can add a service to check the API version. That shouldn't be a big problem.

Quoted 6 lines

4. Introspect
It's becomming common implement a Introspectable interface that make possible get a xml string describing the provided services. It can be a good feature support it.
Quoted 1 line
From my point I try to avoid using XML wherever possible.

Regards

Marcel